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AMENDMENTS TO THE SPECIFICATION 

Please replace the paragraphs on pg. 17, I. 16 through pg. 18, I. 22 of the Specification 
with the following: 

The inbound communication channel 210 is for server-to-client communication and client 
message delivery acknowledgements. This channel 210 uses a messaging pattern that is reversed 
from the normal HTTP communication pattern as illustrated in Figure 4 to which specific 
reference is now made. To initiate this channel 210, the client 204 sends 228 an HTTP "request" 
(i.e., a first HTTP -based "request") asking for messages to the web proxy 200, which then 
forwards 230 this "request" to the server 202 where it is parked. This parking of an HTTP 
"request" at the server 202 establishes a connection setup phase 232 of this inbound 
communication channel 210. The parked "request" enables the server 202 to reply to the client 
204 whenever the server 202 has a message that needs to be sent. 

During this communication phase 234, the server 202 sends 236 an HTTP "reply" with 
the message content to the web proxy 200, which will forward 238 the "reply" with the message 
content to the client 204. This "reply" is in response to the parked "request" previously 
delivered during the connection setup phase 232, and embodies the message that needs to be sent 
from the server 202 to the client 204. In response to the receipt of this "reply", the client 204 
will send 240 a delivery acknowledgement as an HTTP "request" (i.e., a second, third, or 
subsequent HTTP-based "request") in to the web proxy 200, which will then forward 242 the 
HTTP "request" with the message acknowledgement to the server 202. This acknowledgement 
will act as the parked request (i.e., a second, third, or subsequent HTTP -based "request") to 
which the server may then respond with the next message whenever the server 202 generates 
such a message. 

Unlike polling systems that only allow the server to send messages at the discrete times 
of the polling messages, under the protocol of the instant invention the HTTP "request" (i.e. the 
first, second, third, or subsequent HTTP -based "request") is parked at the server 202 to enable 
the server to transmit messages at any point in time that the messages are generated. This 
significantly increases the efficiency of the message transfer since the messages must no longer 
be queued at the server 202 to await a polling request before they may be delivered to the client 
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204. Likewise, the client-generated HTTP message acknowledgement is embodied in a HTTP 
"request" (i.e., a second, third, or subsequent HTTP -based "request") that serves to acknowledge 
that the previous message was successfully delivered, and servers as a parked "request." This 
newly parked request once again allows the server 202 to transmit messages to the client 204 as 
soon as they are generated within the server 202. 

Please replace the paragraph on pg. 20, 11. 3-13 of the Specification with the following: 

In an alternate embodiment of the system and protocol of the instant invention, the client 
generated "request" (e.g., a first request) that is sent to and parked at the server may include a 
request that the server send a reply after a period of time. This will ensure that the client's proxy 
server 200 will not time out and close the connection due to inactivity on the channel. In 
response to this "reply," the client will again send a "request" (e.g., a second request) that will 
remain parked at the server until it has a message to send, or until the suggested time for 
transmission of a reply to avoid proxy connection closure, i.e., even if there are no messages to 
send the client. The time period that the client specifies for this connection maintaining reply 
may be dynamically adjusted based n the particular proxy 200 employed by the client's system, 
or may be sent to a discrete value. Setting a discrete value provides some assurance to the client 
that the connection has not failed for some undetectable reason, such as a TCP/IP drop, etc. 
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